COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	abstra[s85,jmc]		Abstract actions
C00010 ENDMK
C⊗;
abstra[s85,jmc]		Abstract actions

taken from ideas[w84,jmc]
1984 feb 14

Abstract performatives or maybe we should just call them abstract actions.

	To a speech act theorist, a performative is a sentence that
does something by its utterance other than state a fact or command.
Perhaps they have a better definition.  An example is a promise, whose
utterance is not merely a statement of intention but which creates
an obligation to carry out the promise.

	It seems useful in the Elephant style of programming to consider
abstract performatives, e.g. reserving a seat on Flight 177 for
John Searle.  We imagine this as an action the reservation system can
do, but we don't associate with any particular modification of any
database.  Instead it is related to subsequent actions by the
statements,  "If a seat has been reserved for someone, and the
reservation hasn't been cancelled, and he arrives at the gate
at the time of the flight, then he should be allowed on the airplane".
Of course, cancelling a reservation is another abstract performative,
and, perhaps, so is allowing someone on a plane.  The idea is that
the reservation program can be written in terms of abstract performatives,
and the program can refer to past performative events.  It is up
to the compiler to make these abstract actions concrete, e.g. to
store an item corresponding to the reservation in a database.

	All this is related to a comment I made on Moshe Vardi's
New York paper at the conference on logic and computer science.
Vardi discussed how one should update a database in terms of how
a new fact causes changes in the database.  I suggested to him
that one should think of it in terms of events rather than just
in terms of facts, e.g. firing a person and deciding that he had
never worked for IBM at all are distinct events even though they
may result in the same change in a particular database.  If the
structure of the database is modified, they may come to result
in different changes.

	When I told Carolyn about this, she commented something
to the effect that if one thinks about it entirely in terms of
events and their histories, then one doesn't really need the
database as a primary object, and I promptly related this to
Elephant.

May 24

	Let's call them abstract actions rather than abstract
performatives.

	Another example of an abstract action is for the program
to commit itself to some future action or even to achieve a future
goal.  This commitment need have no effect whatsoever.  However,
the correctness of a program depends on commitments being carried
out.  This came out in a discussion with Brian Smith who substantially
agrees.

May 26

	"A program is correct if it carries out its commitments" is
worth exploring as a definition, because we can consider the simple
case of having initial commitments.  However, the idea may be worth
elaborating, since it may turn out to be impossible for some reason
to give every passenger the seat reserved for him.  Therefore, instead
of considering only  correctness,  it may sometimes be worthwhile to
use the concept of  success.  A program is  successful  to the extent
that it succeeds in carrying out its commitments.

1985 May 5

	While reading Scherlis "Deriving efficient graph algorithms",
it comes to seem that it is worthwhile to include abstract actions
in such programs.  Specifically we note that we have seen a vertex
and later can ask about a vertex whether it was seen.  We regard the
action as abstract, because the noting need not be represented by
any specific actual action provided the later references are
carried out correctly.  In this example, we need to distinguish
between noting the pointer and noting the S-expression.

	Scherlis's algorithm shows that we need to refer to "if
I have seen this vertex since ..."

	A cache is a kind of note-maker.  Automatic caches, as in
present computers, represent a bad idea.  The better idea is that
the hardware provides facilities for making the kind of note a
cache represents and the programmer or compiler can provide whatever
algorithm is appropriate for deciding that certain information shall
be retained in high speed store.

	As soon as we refer to the past, we open the possibility that
the result of the algorithm is dependent on the order in which things
are done.  If it is important that the result not be dependent we must
prove it, but this is often a byproduct of a proof that a specific
function is computed.